其他
Vol.19 百分之九十九的软件都会消失，真正的 AI 原生产品怎么设计？
卷首语
最近和团队一直在聊产品设计，基本共识是“靠谱就会死”。
时代变了，原来靠谱的做法就是老路，而大厂在老路上资源更多，而且他们也都想搞 AI，所以只要选择的市场靠谱、打法靠谱，大概率就会撞车，然后被大厂碾过去。
可是，要不靠谱，也不能瞎搞啊，往哪个方向去离经叛道呢？
这时就要把头抬起来，不要只盯着“把 AI 塞到产品里”这个一阶机会，而要更多去想想“如果 AI 成为了所有产品的基座”之后会发生什么，二阶的变化、挑战和机会是什么，这种情况下新的设计范式是什么。看得更远一点，想得更深一点，才能找到少有人走（而且居然正确）的道路。
如果你也想设计 AI 时代的产品，建议把这篇公众号仔细读，然后打开推荐的链接，把这 3 个人其他文章也都通读一遍。先看见未来的模糊样貌，先洗掉一些过时的习惯习气，才更可能创造崭新的世界呀：）
1
GUI & LUI
如果 99% 的软件会消失，要不要提前认命做个 API？
GUI 转化成 LUI，人人都想得到影响是易用性增加，比如不会 Excel 的人也可以通过下命令读表格作图。
不一定人人想得到的，是“意愿解读“（比如画个按钮让人按）和”功能实现“（比如画个图表）之间的解耦，让能力更容易被充分表达。比如 Excel 里 10000 个细微功能，但前端只有 100 个按钮位置（再多人类就学不会了），这样 99% 的功能不会被用到、不会被感知到——比如你只能问我和徐文浩 3 个固定的大模型技术问题，而且只允许我们回答 6 句话，会很难分辨谁技术比较强——能力被表达约束。但如果你可以抓着我俩敞开聊，10 分钟你就可以知道他懂我不懂。
如果“意愿解读”能力有限 & 要求专业，类似我们和每个人都只能问 3 道题，我们就会需要和很多人（软件）合作。但如果 LUI 提供了无限的、通用的”意愿解读“能力，我们还需要那么多人（软件）么？
但再进一步呢？GUI 其实是让用户走我们设计的迷宫，路径有限，知道用户会一步一步怎么走，所以我们很容易设计流程，后台开发也有可能会把很多小模块耦合在一起。但如果默认是 LUI 设计，允许用户东一榔头西一榔头提出需求，我们后台就会默认把能力颗粒度变细，然后一个一个解耦单独放出来（毕竟用户可能单拎这个功能用）。而如果颗粒化的能力，能够被单独调用，这不就是 API 么……
如果能力被细颗粒化 API 化，那么理论上就可以被内部外部广泛调用。同时，如果用户侧流量入口变成 AI Copilot 助理，有能力调用 API，理论上任何需求都可以通过调用成熟外部 API 组装出一个刚刚好的方案。这时，很多的软件和 SaaS 会消失，同时浮现一堆的 API 被 Copilot 调用（可能还会分钱）。类似一个城市，可能原本需要很多的便利店和超市，顾客想买什么东西可以去店里挑。但如果来了个大电商，直接细颗粒度提供便利店里也有的“商品”，而且可以做到 1 分钟送货上门，这样商品销售额可能会上升，但便利店可能要倒掉一片。
所以，其实现在存在一个思考路径，就是直接把自己当做商品，而不要去想门店的事儿。直接思考，自己对于世界来说，可以提供一个怎样的 API，创造怎样独一无二价值（独特的思考，独特的 action，独特的资源和能力），然后尽量让自己被更多次组装和调用。真的能做成入口平台的机会过于稀缺，做成被调用的能力集也不差——比如四通一达，肯定自己都有平台梦想，但现在基本上已经变成了被调用的 API，也不是不能接受。
我之前很喜欢 Web3 的一个概念是“可组合性”（Composability），很可能会在 AI 笼罩下的互联网世界先实现，这事儿挺妙。这时思考更多的不是人机交互界面，而是机机交互，我这个 agent 如何被主 agent 发现，如何被合理调度，如何获取商业价值……以及，为了交付好的结果，我应该如何主动去搜寻、评估和整合其他 agent。
类比来想，其实古典时代的软件更像是手工作坊，每一行代码、每一个零件都是手敲出来。而新时代的软件会更像是工厂，供应链协同几百个其他工厂，从别的工厂进货、自己加工、然后出货，而出的货可能又送往另一个工厂。大规模 agent 协作，相互调用标准化的能力，协同创造。
这样本质的变化过程中，机会在哪里呢？如果注定 99% 的软件会消失，要不要提前认命做个 API？
推荐阅读：
🔗 对话蓝湖任洋辉：从GUI到LUI，自然语言交互将重塑软件
2
GUI & LUI
未来每一天，都会有 10 亿个新软件生成
Geoffrey Litt 的文章给了我很多启发。
之前，我考虑 AI 对产品设计的影响，主要是在考虑如何融合 GUI 和 LUI，比如把高频场景用 GUI、低频长尾场景用 LUI，以及用 GUI 做更多直觉引导约束之类。
但 Geoffery 给了一个不同的思考框架，有没有可能未来除了传统 GUI 和 LUI 之外，还有大量实时生成的 GUI 呢？
我们考虑 GUI 的时候，脑子里隐喻其实更像是操作一台机器，什么交互和功能都是固定的很不灵活，但约束和指引清晰。比如你用画笔（或者 ControlNet）表达构图，肯定比言更容易；比如我们开车的时候操作方向盘，就更容易和车子融入一体产生心流，要都用嘴皮子开车会累死。
而我们考虑 LUI 的时候，脑子里隐喻其实更像是和一个顾问或者助理在沟通，约束和指引模糊，但非常灵活。比如你去店里买东西和店员聊天，不仅可以自由询问“有没有小一号”的这种 GUI 也很容易表达的问题，也可以聊“有没有类似这个款式，但是是白色的”。不一定有效率，但边界非常宽，门槛非常低。
有没有可能结合两者，我们用 LUI 沟通的不是顾问，而是一个机器猫，每次不是直接帮我们解决问题，而是提供针对我这次任务的定制化道具（GUI）给我呢？
比如，现在的 SaaS 软件大部分都可以给不同角色配置不同的 Dashborad，这也可以理解为早期的定制化 GUI。如果极端到每一个人、每一个具体任务，只要是还需要用户后续摆弄摸索的，都提供一次性 GUI 呢？
从这个视角出发，AI-Native 的应用，不仅仅是应该在后台灵活组装 agent 的能力来交付结果，而且也需要在前台自适应创建大量一次性的、最适合完成这次单次任务 & 最适合这个用户的 GUI 方便用户使用。后台是一堆能力的乐高积木块，可以自由拼装，而且可以去网络上选择合适的第三方模块拼装进来；前台也是一堆 GUI 的乐高积木块，根据用户偏好和需求自由拼装，组装成最能够帮助用户达成目的的形态。
如果 GUI 交互界面可以快速生成、组装，那么理论上需要的软件或 SaaS 数量会大幅度减少。类似用 Notion 可以把一些简单的内部流程和 CMS 工具拼装出来，就会减少对专业工具需求。AI 创建新应用（GUI + 后台能力）比用 Notion 还要方便 100 倍，可能会进一步蚕食细分软件市场——为什么要买一个呢，自己生成一个就好呀，自己搞的还放心。换个比方，现在市面上餐厅五花八门，但如果有了完美的机器厨可以听懂客人的要求 & 拿后厨原料定制化炒菜，理论上所有餐厅就会同质化，大家去自己楼下餐厅就能吃到粤菜湘菜日本菜……市面上餐厅就会减少。
只是这样，对于设计者其实提出了更高要求：
交互模式：什么情况下用默认 GUI，什么情况下用 LUI，什么时候成成一个一次性 GUI 给用户？ 能力设计：如何解耦后台的能力，让 LLM 可以随时把能力拆解、重组形成一次性专业方案？ 意图规范：用户如何和 LLM 交互来逐步清晰表达意图？ 数据提取：如何识别模糊的意图，提取相应的、合适的数据来支持用户任务的完成？
用户赋能：什么时候应该用 Copilot 辅助用户，什么时候应该是 Autopiliot 帮忙直接搞定，什么时候应该是为用户生成专属 GUI 方便用户自己搞？
原来的 PM，很多时候只是写 PRD 和画交互的角色，但现在……活儿很重啊。
推荐阅读：
🔗 https://www.geoffreylitt.com/2023/03/25/llm-end-user-programming.html?utm_source=bensbites&utm_medium=newsletter&utm_campaign=have-you-been-a-bard-boy
3
AI NATIVE
AI 原生，不意味着一个空白对话框
ChatGPT 之后，我们有一种倾向，就是把所有 UI 都设计成对话。
听了 Linus Lee 一个分享，很喜欢他的视角和框架：对话式 UI 给我们提供的是灵活性（flexibility），我们可以在其之上，用其他的 UI 来提高直觉性（intuitive）和易用性（easy to use），不要用一个对话框解决所有问题。
首先，哪怕我们认为就应该用对话式 UI，也不应该局限在 ChatGPT 模式上。因为 ChatGPT 的对话，和现实中对话相比有一个显著不同，就是缺乏上下文（context）。比如两个人面对面喝咖啡，一人看了一眼甜品柜，转头和朋友说”再来个拿破仑怎么样？“，她朋友大概率能 Get 到是问她要不要拿破仑蛋糕，而不是忽然要讨论历史问题；又比如你在一家公司工作了 3 年，多少都能有点了解你老板性格，比如她特别讨厌细节，那么当她要你“给我邮件说一下 X 项目进展”，你会默认只写要点。
ChatGPT 的上下文窗口很小（Claude 100k 虽然看起来很大，但我试下来体验也很糟），这就导致对话时其实要做“每次表达时要把所有信息（背景，偏好，前情提要……）都塞进来”的假设，这就很让人无语。
真实设计时，哪怕我们仍然以对话为 UI，我们也可以更多把上下文信息包含进去，比如用户正在什么软件里，打开了什么文档（当用户说”把这个文档发给 XX“的时候，至少知道”这个文档“是什么），鼠标在哪里，选择了什么（当用户想要改写一段话的时候，用鼠标选择这段话然后让 AI 改，比用嘴讲清楚到底是哪一段要更轻松）。
一次交互过程，不仅是你一句我一句对话，而应该拆解成 4 个部分：
意图（intent）：用户的指令，或者疑问 上下文（context）：解读用户指令和决定的场景相关信息 解读（rollout）：对用户意图的识别和理解 行动（action）：反应、行动
而在这个过程中，Linus 提示了一个很有意思的表达形式：名词，然后动词。先在上下文中，把需要操作的对象标识出来（point and select），然后再看我们要对其做什么动作（action）。如果用其他 UI 标识更直觉、更方便（比如用鼠标选一段话，用相机拍摄一页书，把文件拖到框里，群里@一个人），如果用其他 UI 来展示动作更方便（比如右键菜单，比如命令行补全），就用啊。
那么，如何平衡 GUI 和 LUI 呢？
Linus 觉得 LUI 增加了灵活性，但是降低了直觉性。具体来说，LUI 在给人直观引导方面，仍然有不如 GUI 的地方，比如初级用户面对一张白纸会很迷茫，不知道自己可以做什么。直接 LUI 的学习曲线过于陡峭，什么都有赖于用户的主动发现，这不是好的 onboarding 过程。GUI 给了更多的限制，但也让选项和路径明显，大家上手会更轻松。
而除了行动本身之外，也可以用其他的 UI 方式来闭环。比如给用户多个产出物选择（Midjourney 和 Jasper Template 都会产出多个结果让用户选），比如给用户更多后续交互提示（比如 New Bing 在 Chat 后浮现推荐的后续问题，比如百度里搜索美元汇率会出现 GUI）。
总的来说，Linus 认为一个好的对话式界面应该：
在 workspace 里有 agent（我的理解是能感知上下文） 充分利用丰富的共有上下文（最好是不用说话，就能知道我啥意思） 有一个让人愉悦的路径引导（不指望用户对着白纸搞清楚怎么用，能一步步引导用户掌握玩法） 搞不定了，总有对话框可以兜底（因为对话灵活，就类似客服电话里”按 0 呼叫人工坐席”） 把交互闭环掉，加快迭代进化（这也是应用积累壁垒的一种可能性）
AI 原生的产品设计，并不是说“加个 LLM 对话框做 Copilot”，而是需要基于 LLM 能力和限制，重新设计能力和交互，帮助用户完成他的 JTBD。
推荐观看：
📹🔗 https://www.youtube.com/watch?v=rd-J3hmycQs